hhkb
FDEFDE개요 · 01

FDE의 업무 방식

작성자 : Heehyeon Yoo|2026-05-26
# FDE# FDE개요# Forward Deployed Engineer# 커리어# Palantir

Forward Deployed Engineer(FDE)는 고객 환경 안에 들어가 제품을 실제로 돌아가게 만드는 엔지니어다. 본사에서 기능만 쌓는 게 아니라 현장의 데이터, 규제, 업무 흐름에 맞춰 통합하고 배포하고, 쓰이게까지 책임진다.

FDE란 무엇인가

FDE는 2009년경 Palantir에서 본격적으로 쓰이기 시작한 직함이다. Palantir는 Foundry, Gotham 같은 플랫폼을 정부, 금융, 대기업에 넣을 때 고객이 스스로 붙이기엔 제품이 너무 복잡했다. 그래서 고객 팀 옆에 앉아 미션을 이해하고 통합 코드를 짜고 운영 환경에 맞게 맞추는 엔지니어가 필요했다. 그게 FDE다.

직함의 뜻은 군사 용어에서 온다. 본부가 아니라 전선(forward)에 배치(deployed)된다는 이미지다. 티켓 큐 뒤에서 답장하는 지원이 아니라 고객 인프라와 조직 안에서 문제를 푼다.

2023년 이후 OpenAI, Anthropic, Runway, Greptile 같은 AI와 엔터프라이즈 스타트업이 같은 이름의 채용을 늘리면서 업종 전반으로 퍼졌다. 회사마다 정의는 조금씩 다르지만 공통분모는 "고객 곁에서 프로덕션급 코드를 쓰고 결과를 책임진다" 쪽에 모인다.

왜 이 역할이 필요한가

좋은 제품만으로는 부족한 경우가 많다. 플랫폼형 제품은 능력은 넓은데 고객마다 데이터 형태, 권한, 레거시, 컴플라이언스가 달라서 그대로 꽂으면 안 맞는다. 발견 미팅 몇 번으로는 안 나오는 제약이 현장에만 있다.

FDE는 그 간격을 메운다. "제품이 할 수 있는 것"과 '이 고객이 지금 필요한 것' 사이를 코드와 설정으로 연결한다. 성공 기준이 슬라이드나 보고서가 아니라 프로덕션에 올라가고 사람이 쓰고 계약이 이어지는 쪽에 가깝다.

하는 일

회사와 프로젝트마다 비중은 다르지만 보통 아래 범위가 겹친다.

발견(discovery)
이해관계자와 만나 실제로 중요한 문제가 무엇인지 맞춘다. 현업, 경영, 보안이 각각 다른 말을 할 수 있어서 말한 요구와 진짜 병목을 구분하는 일이 들어간다.

설계와 구현
데이터 파이프라인, API 연동, 맞춤 워크플로, 내부 도구, 에이전트, RAG 같은 형태로 프로덕션에 들어갈 코드를 쓴다. 데모용 스크립트 한 번이 아니라 고객 환경에서 돌아가게 만든다.

배포와 운영
SSO, VPC, IAM, 데이터 거주, HIPAA, FedRAMP 같은 제약 아래 배포한다. 새벽에 깨진 파이프라인을 고치는 것도 FDE 몫인 경우가 많다.

제품 피드백
여러 고객에서 반복되는 요구와 막힘을 본사 제품 팀에 넘긴다. 다음 고객이 매번 원오프 스크립트를 쓰지 않게 플랫폼이 바뀌는 루프가 생긴다.

Palantir 쪽은 한 고객에 오래 박혀 대규모 기관을 다루는 그림이 많다. AI 스타트업 FDE는 POC를 일주일 안에 맞추고 경쟁사와 비교하는 짧은 사이클이 흔하다. 속도와 스코프는 다르지만 '현장에서 끝까지 가져간다'는 점은 같다.

전형적인 업무 흐름

조직마다 도구는 다르지만 흐름은 비슷하게 반복된다.

  1. 고객 팀에 임베드하거나 밀접하게 협업한다.
  2. 도메인, 데이터, 업무를 빠르게 학습한다.
  3. 문제 정의를 맞추고 작은 단위로 POC, MVP를 만든다.
  4. 산출물을 보여 주며 피드백을 받고 범위를 조정한다.
  5. 프로덕션 배포와 사용자 온보딩까지 간다.
  6. 안정화 후 운영을 넘기거나 다음 페이즈, 확장 계약으로 이어진다.

외주에서 흔한 "언제 되나요?"만 기다리는 관계와 달리 FDE 쪽이 먼저 돌아가는 결과물을 들고 와서 다음 단계를 여는 경우가 많다. 말로만 합의한 내용이 며칠 뒤 화면, API, 파이프라인으로 보이면 신뢰가 빨리 쌓인다.

계약 전에도 POC, MVP를 들고 세일즈에 참여하는 회사가 있다. 예전에는 계약 전 POC 투입을 꺼리던 문화와 다르게 요구가 조금만 와도 빠르게 만들어 보여 주고 다음 페이즈를 논의하기도 한다. 다만 이건 회사 정책 차이이지 FDE라는 직함의 필수 조건은 아니다.

다른 역할과 어떻게 다른가

솔루션 엔지니어, 세일즈 엔지니어
주로 계약 전에 기술 데모, 아키텍처 제안, 보안과 규제 질문에 답한다. 딜이 끝나면 구현 팀으로 넘기는 구조가 많다. FDE는 계약 후에도 남아 프로덕션 코드와 결과를 책임지는 경우가 많고 세일즈 쿼터를 지는 조직도 드물다.

컨설턴트
분석, 권고, 로드맵이 중심인 경우가 많다. FDE는 보고서보다 돌아가는 소프트웨어를 남기는 쪽에 가깝다.

SI, 외주
겉으로는 파견, 현장 투입이 비슷해 보인다. 차이는 주도성과 문제 정의 방식에 있다. 명세서대로만 만드는 그림보다 현장을 보고 무엇을 만들지 스스로 좁혀 가는 비중이 크다. 고객이 진행을 추궁하는 관계가 아니라 FDE가 결과물을 먼저 보내고 피드백을 받는 패턴도 있다.

일반 고객 지원
티켓 기반 1차 응답과 달리 같은 고객, 같은 스택에 오래 붙어 깊게 파고든다.

구분FDE솔루션/세일즈 엔지니어컨설턴트
프로덕션 코드씀드묾안 씀
계약 후 책임보통 있음보통 없음산출물과 조언 중심
고객 임베드장기영업 사이클프로젝트 단위

필요한 역량

기술
Python, TypeScript, SQL, 클라우드(AWS, GCP), Docker, Kubernetes 정도는 기본으로 깔린다. 레거시 ERP, DB, SSO 연동, 고객 VPC 안 배포 경험이 채용 공고에 자주 올라온다.

현장
애매한 요구를 쪼개고 지금 당장 만들 것과 나중 것을 가른다. 고객 앞에서 말하고 동시에 손으로 구현할 수 있어야 한다. PM 없이 아키텍처 결정을 내리는 순간도 있다.

제품 감각
'요청받은 기능'보다 "지금 이 고객에게 가치 있는 것"을 고르는 눈이 필요하다.

AI 제품 FDE(2020년대 후반)
에이전트 오케스트레이션, 모델 출력 평가, 프로덕션에서의 환각과 품질 추적 같은 요구가 늘고 있다. 코딩만 잘해서는 부족하고 LLM, 파이프라인이 현장에서 왜 깨지는지 추론할 줄 알아야 한다.

AI 시대에 FDE가 늘어난 이유

엔터프라이즈 AI는 데모는 쉬운데 고객 데이터, 권한, 감사 로그까지 맞추면 난이도가 확 올라간다. 그래서 "첫 통화부터 프로덕션까지" 한 엔지니어가 고객 관계를 잡는 모델이 AI 회사에 잘 맞는다. 2025년 전후 FDE 채용 공고가 급증한 배경도 여기에 가깝다.

동시에 회사마다 FDE 정의가 제각각이라 같은 직함이라도 한곳은 거의 세일즈 엔지니어에 가깝고 다른 곳은 Palantir식 장기 임베드에 가깝다. 오퍼를 볼 때는 JD와 조직(엔지니어링인지 세일즈 보고인지)을 꼭 확인하는 게 좋다.

정리

FDE는 현장의 복잡한 요구를 받아 제한된 조건 안에서 실제로 돌아가는 형태로 만드는 역할이다. 운영만 하는 사람도 아니고 논문만 설명하는 사람도 아니다. 제품 능력과 고객 현실 사이를 코드로 잇고 그 결과가 쓰이게까지 가져가는 제너럴리스트에 가깝다.

참고 자료